Add mako Docker image for performance testing#13159
Conversation
There was a problem hiding this comment.
Pull request overview
Adds an opt-in Docker image target for the mako benchmark so it can be deployed in Kubernetes-based performance/regression testing flows, enabled via BUILD_MAKO=1.
Changes:
- Add a new
makostage/target topackaging/docker/Dockerfilethat packages an architecture-specificmakobinary. - Gate inclusion/build/push behavior for the
makoimage inpackaging/docker/build-images.shbehindBUILD_MAKO=1. - Strip debug symbols for the
makotarget in the C bindings CMake build.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| packaging/docker/Dockerfile | Adds a new mako image stage that installs mako and runs it as fdb. |
| packaging/docker/build-images.sh | Adds BUILD_MAKO gating to include mako in website prep and image build list. |
| bindings/c/CMakeLists.txt | Strips debug symbols from the mako target during packaging. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| chmod +x /usr/bin/mako && \ | ||
| rm -rf /tmp/* | ||
|
|
||
| RUN mkdir -p /var/log/fdb-trace-logs |
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Add an opt-in mako Docker image target to the build system. The mako benchmark binary is packaged into a minimal container for use in k8s performance regression tests. Build with BUILD_MAKO=1 to include it. - Add mako stage to Dockerfile - Add mako to build-images.sh (gated on BUILD_MAKO=1) - Strip debug symbols from mako binary
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
| fi; \ | ||
| cp "/tmp/mako.${FDB_ARCH}" /usr/bin/mako && \ | ||
| chmod +x /usr/bin/mako && \ | ||
| rm -rf /tmp/* |
There was a problem hiding this comment.
It's worth noting that this rm doesn't save any space, because these files were added in the previous layer (directive). But I don't see a better way 🤷
|
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
|
Mac builds stepping on each other? |
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Yeah ... I'm not sure how ... the exclusion lock thing seems to work, only one build runs at a time, but sometimes we see strangely missing files, almost like an rm -rf cleanup was run concurrently ... |
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Yeah it looks like the background-ssh-process lock is terminating in the middle of the build sometimes. The idea there was for the lock to be released if the builder completely died, killing the background ssh process as well. Hmm, could change that for a timestamp check, assume lock is held for up to 1hr (unless released early by healthy builder) |
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
|
I've temporarily removed the requirement of macOS builds to pass |
@ploxiln poking around, mac builds seem to be having issues... compile fails because missing dirs... likely because another concurrent build removed them (didn't look closely). I did remove a /tmp/ci.lock that was a few days old from the m1. |
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
|
Definetly unrelated RandomSeed="2072652414" SourceVersion="248a8a68da91efb45ac1e66f1387dc7b435f6917" Time="1778265802" BuggifyEnabled="1" DeterminismCheck="0" FaultInjectionEnabled="1" TestFile="tests/fast/AtomicBackupCorrectness.toml" |
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Add an opt-in mako Docker image target to the build system. The mako benchmark binary is packaged into a minimal container for use in k8s performance regression tests. Build with BUILD_MAKO=1 to include it.
(Mako is FDB's native C benchmark tool. It's a simple load generator that connects directly to FDB using the C client library and runs configurable workloads — random reads, writes, inserts, range scans — against a keyspace. It's built from source in bindings/c/test/mako/. Compared to YCSB (Java-based), mako is lighter weight, lower overhead, no JVM, and already part of the FDB codebase.)